IIIHI 1 1 11) I II Illll 1 1 



US 20010056503A1 

(19) United States 

(12) Patent Application Publication <io) Pub. No.: US 2001/0056503 Ai 

Hibbard (43) Pub. Date: Dec. 27, 2001 



(54) NETWORK INTERFACE DEVICE HAVING 
PRIMARY AND BACKUP INTERFACES FOR 
AUTOMATIC DIAL BACKUP UPON LOSS OF 
A PRIMARY CONNECTION AND METHOD 
OF USING SAME 



(76) Inventor: Richard J. Hibbard, Bradenton, FL 
(US) 

Correspondence Address: 
Proskauer Rose LLP 
Patent Department 
1585 Broadway 
New York, NY 10036 (US) 



(21) Appl. No.:- 

(22) Filed: 



09/844,291 
Apr. 27, 2001 



Related U.S. Application Data 

(63) Non-provisional of provisional application No. 
60/199,995, filed on Apr. 27, 2000. 

Publication Classification 

(51) Int. CL 7 G06F 15/16 

(52) U.S. CI 709/250; 709/227 



(57) 



ABSTRACT 



A network interface device to connect a network to a virtual 
private network comprises a primary interface to a public 
network, such as an Ethernet interface to a WAN or the 
Internet, and a secondary, back-up interface to the public 
network. The secondary back-up connection is activated 
automatically when the primary connection fails. The net- 
work interface device may be provided with further func- 
tionality that enables secure communication over both the 
primary and secondary connection 
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NETWORK INTERFACE DEVICE HAVING 
PRIMARY AND BACKUP INTERFACES FOR 
AUTOMATIC DIAL BACKUP UPON LOSS OF A 
PRIMARY CONNECTION AND METHOD OF 
USING SAME 

RELATED APPLICATION 

[0001] This application is related to and claims the benefit 
of U.S. provisional patent application Scr. No. 60/199,995, 
filed Apr. 27, 2000 and entitled Automatic Dial Backup/ 
Network Failover. The content of this provisional applica- 
tion is incorporated herein by reference. 

FIELD OF THE INVENTION 

[0002] The present invention is directed to a network 
interface device and method for automatically activating a 
back-up connection between the network interface device 
and a public network when a primary connection fails. The 
present invention has particular applicability to secure com- 
munications networks, such as a Virtual Private Network 
(VPN). 

BACKGROUND OF THE INVENTION 

[0003] A VPN is a network that is deployed over some 
type of shared infrastructure, such as a WAN or the Internet, 
that is normally available to the public. Nonetheless, a VPN 
can be securely used to link private resources at nodes of the 
VPN without giving the public access to the VPN network. 
Such a node may comprise a single computer that links over 
the VPN to a network or, more typically, the node may be a 
network of computers that links with another network of 
computers. A VPN is useful because nodes (i.e. computer on 
networks) in different locations can be linked via the public 
infrastructure instead of over expensive, privately- leased 
lines. Thus, for example, a company having offices in 
different buildings, cities, or countries can avoid the expense 
of maintaining its own leased lines to link the various pieces 
of its network, and could instead securely use the public 
network as the link. 

[0004] The use of any tunneling protocol, such as IPSec 
(Secure Internet Protocol), makes it possible to create the 
VPN through "tunnels" over the Internet. "Tunneling" 
involves encapsulating data packets in a network protocol 
within TCP/IP packets. The network protocol is known at 
the entry and exit points, or "tunnel interfaces," of a given 
network, but not on the public network so that if the packets 
are intercepted the data within them remains secure. The 
tunnel interface itself is similar to a hardware interface, but 
is configured in software. 

[0005] As with all networks, it is important to maintain the 
network connection between the nodes of a VPN at all times. 
The nodes are typically reliably linked to the WAN or 
Internet with Ethernet connections. However, a node's Eth- 
ernet connection to the WAN or Internet can fail either 
because the public interface on a network interface device 
between the network and gateway goes down or because the 
primary WAN or Internet gateway used by the device goes 
down. In either case, the node remains unconnected to the 
rest of the network until the connection is restored at some 
future point, which may take a while. Alternatively, the 
connection of the node to the rest of the network may be 
manually rerouted through an alternate connection, which is 



time consuming and requires a network administrator to first 
recognize that the connection has been lost. 

[0006] While loss of a connection to a public infrastruc- 
ture like the Internet is especially significant for VPN'S, it 
is also a problem for all networks that utilize resources on a 
public network like the Internet. When the connection to the 
Internet is down, the resources on the Internet cannot be 
accessed. 

SUMMARY OF THE INVENTION 

[0007] It is therefore an object of the present invention to 
provide a network interface device and method for auto- 
matically activating a back-up connection should the pri- 
mary connection fail. This minimizes the overall downtime 
until the primary interface is restored. 

[0008] It is a further object of the present invention to 
enable a back-up connection which only requires a mini- 
mum of additional processing and network overhead. 

[0009] These objectives are achieved in accordance with 
an embodiment of the present invention in which a network 
interface device is provided. The device comprises a private 
interface for connecting to one of a computer and network 
of computers, a primary public interface for a public net- 
work, such as a WAN or the Internet, and a back-up public 
interface for connecting to the public network using a 
secondary connection, such as a dial-up connection to an 
Internet Service Provider (ISP). The network device auto- 
matically activates the back-up connection when the primary 
connection fails for whatever reason using a software appli- 
cation executable at the network interface device. 

[0010] The status of the primary connection is monitored, 
such as by sending ICMP pings over the primary public 
interface to a target IP address on the public network. If the 
primary connection fails, the secondary connection is estab- 
lished and is maintained until the primary connection is 
restored. The restoration of the primary connection may be 
determined by pinging the target IP address through the 
back-up connection. When the primary connection becomes 
available, it may be automatically or manually restored. 
Where the network interface device connects to a VPN, the 
device also generally comprises encryption and compression 
utilities and other functionality that enables secure private 
communications to take place over the public network. 

[0011] Other objects and features of the present invention 
will become apparent from the following detailed descrip- 
tion considered in conjunction with the accompanying draw- 
ings. It is to be understood, however, that the drawings are 
designed solely for purposes of illustration and not as a 
definition of the limits of the invention, for which reference 
should be made to the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0012] In the drawings, wherein like reference numerals 
denote similar elements through out the several views: 

[0013] FIG. 1 is a block diagram depicting an example of 
a virtual private network that has both a primary Ethernet 
connection between two nodes and a back-up modem con- 
nection; 

[0014] FIG. 2 is a block diagram of some of the basic 
components of the network interface device in accordance 
with an embodiment of the present invention; 
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[0015] FIG. 3 is a flow chart of an algorithm for auto- 
matically switching to a back-up connection when the 
primary connection fails and for automatically restoring the 
primary connection when it becomes available again; and 

[0016] FIG. 4 is a flow chart detailing the algorithm that 
is performed at step 250 of FIG. 3. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

[0017] FIG. 1 shows an example of a VPN in accordance 
with the present invention. In this example, a first network 
Network 1 comprises a node with multiple computers 10, 
20, 30, a workstation 40, and a server 50 all linked to a hub 
60. A network interface device 70 provides a first, private 
Ethernet interface ethO to hub 60 and a second, public 
Ethernet interface ethl to a VPN cloud 80 (e.g., a commu- 
nications network), EthO may be a standard IEEE 802.3 
Ethernet gateway. Device 70 provides hardware and soft- 
ware for implementing VPN functionality over a public 
network, such as the Internet or WAN. The functionality 
may include high-speed point-to-point encryption and com- 
pression of data, data integrity checking, hardware authen- 
tication, key management, secure gateway administration, a 
firewall for network security, routing protocols, key man- 
agement, etc. One group of devices that offer all or some of 
this functionality are the Net Fortress family of products 
from Fortress Technologies, Inc. of Oldsmar, Fla. Network 
1, as illustrated, does not have a secondary back-up interface 
to cloud 80, although it could. 

[0018] A second node of the VPN comprises a network 
Network 2 comprising three workstations 100, 110, 120 
connected to a hub 130. Hub 130 connects to a second 
network interface device 140 provided for Network 2 at a 
private ethO interface on device 140. Device 140 connects to 
cloud 80 at a public ethl interface, which also may be a 
standard 802.3 Ethernet gateway. A secondary back-up 
interface pppO is provided for Network 2 to connect to cloud 
80 using a high-speed modem 150. Secondary interface 
pppO is a high-speed serial PPP (point-to-point protocol) 
interface to an ISP router 160 that links to cloud 80. It is this 
secondary pppO interface that provides the back-up connec- 
tion for Network 2 to cloud 80. It should be understood that 
while a dial-up connection using modem 150 is shown as an 
illustrative example, any type of secondary connection may 
be used. Modem 150 is given as an example because it is a 
relatively simple device to implement and oftentimes net- 
work interface device 140 has an existing serial port to 
which a modem can easily interface. 

[0019] FIG. 2 illustrates some of the basic components of 
network interface device 140 including central processing 
unit 142, an interface software application 144 that provides 
the device functionality, the back-up utility 146, and a buffer 
148. The backup utility 146, which may run in the back- 
ground and may be implemented as a stand-alone utility, 
comprises a PPPD daemon for polling the primary connec- 
tion for possible failures , a BackUp daemon for automati- 
cally switching to a secondary connection using the backup 
pppO interface if a failure is detected, and an optional 
Failover daemon for automatically restoring the primary 
connection through the ethl interface when the primary 
connection is restored. 

[0020] The dial backup utility 146 monitors the status (UP 
or DOWN) of the primary connection that is established 



between the ethl interface and the router or gateway inter- 
face that is closest to device. The failure of the primary 
connection may be caused by one or more problems, such as 
a problem at the router or gateway interface, a cable fault 
between the ethl interface and the router or gateway inter- 
face, or a problem at the ethl interface itself. 

[0021] In one embodiment, the monitoring of the primary 
connection occurs by periodically polling the public inter- 
face ethl and checking for responses. One method of polling 
involves sending I CMP (Internet Control Message Protocol) 
pings comprising 64-byte ICMP packets to one or more 
designated target IP addresses, for which an acknowledge- 
ment should be received if they successfully reach their 
target. It should be understood, however, that any other 
method of monitoring could be alternatively used in lieu of 
polling with ICMP packets. If no acknowledgement is 
received, this is assumed to indicate that the primary con- 
nection to cloud 80 is down. 

[0022] The target IP addresses that are pinged may be any 
known IP addresses accessible over the Internet such as the 
IP address of a local gateway at the Internet service provider 
(ISP), the IP address of a gateway at Network 1, or an IP 
address of a particular server. Generally though, at least one 
target IP address to be pinged will include the IP address of 
the first router or gateway on the Internet that is closest to 
device 140. The particular IP addresses to be pinged will 
typically be related to the purpose of the monitoring. In one 
embodiment, at least two target IP addresses are pinged. This 
may include the IP address of the first router or gateway on 
the Internet that is closest to device 140 and an IP address 
for a network device that is further away from the ethl 
interface. 

[0023] FIG. 3 is a flow chart illustrating the steps by 
which the system monitors for a failure of the primary 
connection and switches to the backup connection as nec- 
essary. At step 200, certain parameters are initially config- 
ured in the PPP daemon according to settings in a configu- 
ration file at device 140. These parameters include (1) first 
and second IP addresses to be monitored to determine 
whether the primary connection is available to connect to the 
public network; (2) the frequency of pings that should be 
sent per polling period; (3) the number of times the system 
should retry to reach the primary connection if the connec- 
tion is not successfully pinged with a first series of pings; 
and (4) the delay between ICMP rounds of pings. 

[0024] At step 210, for each of the two target IP addresses, 
an ICMP ping is sent n times with a frequency based on the 
value of the frequency parameter set in the configuration file. 
The results of the pings, i.e. whether a response is received 
to each ping, are stored into a local buffer 148 at device 140. 
The results are then analyzed at step 220. If the result of the 
n pings shows that the connection status is UP (e.g., all n 
pings were successful or at least most of them, depending on 
the system setting), then the pinging stops ("sleeps") tem- 
porarily for a particular interval based on the setting of the 
delay value, at step 230. The pinging resumes at the end of 
the delay interval (step 210) with a series of n additional 
pings to again check the primary connection. 

[0025] If, at step 220, it is determined that the result of the 
ICMP pinging is an invalid response and the value of the 
retry parameter has not yet reached the maximum value that 
has been set, then the connection status of the primary 
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connection is set to DOWN, the "retry" count whose maxi- 
mum value is set in the configuration file is incremented by 
1, the invalid response is logged, and, after a timeout at step 
230, the two target IP addresses are again polled with 
another series of n pings at step 210 to check whether a valid 
response is now received. The retry setting enables the 
system to essentially ignore momentary outages or system 
unavailability. 

[0026] If, at step 220, it is determined that the results of the 
I CMP pinging of either target IP address is an invalid 
response or no response and the value of the retry parameter 
has reached the set maximum value (i.e. the retry count is 
exhausted), then the system assumes at step 240 that the 
primary connection is DOWN. At this point, pertinent 
information is logged such as the time and date of the failure, 
the DOWN connection status, and the dialing events such as 
the target addresses that were polled and the time of the 
unsuccessful poll. Also, at step 240, the Ethernet interface 
ethl of device 140 is set to DOWN in device software, any 
security drivers such as the Fortress Tech SPS virtual 
security driver that runs in conjunction with ethl on the Net 
Fortress family of products is set to DOWN, the PPPD is 
stopped if it was running, and a timeout period is provided 
to enable the stopping of the drivers and the new settings to 
take effect (a delay of approximately 3 seconds should be 
sufficient). 

[0027] At step 250, the back-up connection is initiated and 
an alarm may be sent to the system administrator. Turning to 
FIG. 4, which is a flow chart providing further details about 
step 250, at step 251, the ISP is dialed using modem 150. At 
step 252, there is a waiting period for the connection to be 
completed (the length of which may possibly as long as 
approximately 40 seconds or longer, but it depends on the 
speed of the modem and the connection). Once the back-up 
connection is established by the ISP, at step 253, the IP 
address temporarily assigned to the back-up connection by 
the ISP (possibly by extracting it with an AWK script 
available for Unix) is captured and, at step 254, that address 
is assigned in software at device 140 to interface pppO. At 
step 255, the ISP's default gateway for the pppO daemon is 
similarly extracted from the ISP. The ethO 's nctmask (the 
network mask which shows how to divide an Internet 
address into network, subnet, and host parts and limits the 
values that may be placed in those fields) is also extracted at 
step 256 for use with the extracted IP address in setting up 
the tunnels for the VPN. 

[0028] Also captured at step 256 is the ethl setting for IP 
masquerading (enabled or disabled), which either enables or 
disables whether Network 2 can interact with a publicly 
accessible network device on the public network (set to 
enable) or can only interact with a device in the VPN (set to 
disable). If IP masquerading is enabled, network address 
translation is invoked to bind a network address translation 
table to the pppO interface instead of to the ethl interface so 
that the same IP masquerading setting is automatically 
maintained at the pppO interface. The network address 
translation maps the private address of a VPN network 
device in a data packet to a routable address of a VPN for 
purposes of communicating with a device on the public 
network and vice versa for packets going in the opposite 
direction. 

[0029] The Fortress Tech SPS protocol or other security 
protocol, if any, is bound with the pppO interface (step 257), 



a pppO default gateway is added (step 258), the new pppO 
status is logged in a log file to maintain a status record (step 
259), and tunnels to the remote Network 1 side which had 
originally been established by the ethl interface pursuant to 
the tunneling protocol that is used must be re-established but 
now with the pppO interface (step 260). Step 260 includes 
the task of notifying the remote peers to which the connec- 
tion had been lost to use the new pppO interface in place of 
the original ethl public IP interface. At this point, the 
back-up connection using the pppO interface is up and 
running, all routes, both secured and unsecured are re- 
established, and network traffic can resume, albeit, in this 
example, at the relatively slower speed of the back-up 
connection. 

[0030] Returning to FIG. 3, with the back-up connection 
functioning, at step 265 it is determined whether the Failover 
daemon is enabled. If the Failover daemon is not enabled, 
then at step 267, the connection through the pppO interface 
is maintained until the primary connection is manually reset. 
A manual reset may be desirable to give the system admin- 
istrator an opportunity to determine the source of the prob- 
lem and to correct it. It also provides a way to prevent a 
"thrashing" condition in which multiple attempts are made 
to reconnect to the primary connection when the primary 
connection is not yet back up. Thrashing may occur, for 
example, where the primary connection failed due to a cable 
fault or a problem at the ethl interface of device 140, but the 
target IP address is successfully pinged through the second- 
ary back-up connection because the target IP address is a 
functioning gateway interface nearest the non-working ethl 
interface. 

[0031] If the Failover daemon is enabled, the Failover 
daemon attempts at step 270 to detect when the primary 
connection has been restored. The Failover daemon may 
specify a time delay before attempting a reconnection 
through the ethl interface of device 140 in order to enable 
a system administrator to try to resolve the problem. The 
Failover daemon continues to monitor the primary connec- 
tion, for example, by periodically sending a series I CMP 
pings through the pppO interface to the target IP address. If 
the pings do not reach the target as determined at step 280, 
the back-up connection is maintained at step 290. If the 
pings do reach the target, the successful pinging may be 
logged, the pppO interface is disconnected, and the Back-up 
daemon is exited at step 300, 

[0032] The primary interface is re-established using a 
"fallback" utility at step 310. This fallback utility sets the 
Ethernet interface ethl of device 140 to UP, sets any security 
drivers such as the Fortress Tech SPS virtual security driver 
that runs in conjunction with ethl to UP, and a timeout 
period is provided to enable the stopping of the drivers and 
the new settings to take effect (a delay of approximately 3 
seconds should be sufficient). If IP Masquerading is enabled, 
it is invoked to bind a network address translation table to 
the ethl interface instead of the pppO interface. (If the 
masquerading is off, the netmask is only associated to the 
target IP address.) The SPS protocol or other security 
protocol, if any, is again bound with the ethl interface. Also 
at step 310, all secured routes are redirected to the original 
primary interface and tunnels are re-established to the 
remote peers including the sending of route updates. The 
algorithm then returns to step 210 to monitor the status of the 
primary ethl interface. 
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[0033] The above-described algorithm may be substan- 
tially described in pseudo-code as follows: 

[0034] Initialize configuration: 

[0035] Read DialBkup.cfg 

[0036] Get_delay 

[0037] If file does not exist or invalid data, log 
error and exit. 

[0038] Get_addr 1 

[0039] If invalid data, or address format, log 
error and exit. 

[0040] Get addr 2 

[0041] If invalid data, or address format, log 
error and exit. 

[0042] Getjrequency 

[0043] If invalid data, log error and exit. 
[0044] Get_retries 

[0045] If invalid data, log error and exit. 

[0046] Create keep alive.log and write current time 
and date. 

[0047] Main Processing Loop: 

[0048] Send ping n times based on frequency value 
to addr 1. 

[0049] Send ping n times based on frequency value 
to addr 2. 

[0050] Read result into local buffer. 

[0051] If results=valid response, from both desti- 
nations, 

[0052] Set connection status to UP 

[0053] Sleep for n interval based on delay value 

[0054] Repeat polling loop. 
[0055] Else if results=invalid response, 

[0056] Set connection status do DOWN 

[0057] If retry count !=max, 
[0058] Increment retry count 
[0059] Log the request timeout 
[0060] Repeat polling loop. 

[0061] Else 

[0062] Log time and date of failure 

[0063] Log connection status 

[0064] Log Dialing events 

[0065] Set ethl interface to DOWN 

[0066] Set sps interface to DOWN 

[0067] Ensure pppd was not running If run- 
ning, stop it. 

[0068] Wait 3 seconds for processes to stop 

[0069] Initiate ISP dial up 



[0070] Wait for connection to complete (sleep 
40) 

[0071] Get IP for pppO interface 

[0072] Get ppO's default gateway 

[0073] Get ethO's netmask 

[0074] If IP Masquerading enabled, Invoke it. 

[0075] Configure sps with new public IP 
(pppO) 

[0076] Add pppO default gateway 

[0077] Log new pppO status 

[0078] Call nfroute to re-establish tunnels on 
remote side. Notify remote peers to use new 
pppO IP In place of original ethl public IP. 

[0079] (cmd: nfroute -v -n [private net] -m 
[private net 

[0080] mask] -g [pppO IP address] -s [public 
IP of remote peer] 

[0081] Restart local nfd to re-establish tun- 
nels to remote Peers, (cmd: kill -HUP nfd- 

. P id) 

[0082] If configured, invoke ethl fallback. 

[0083] Exit dial backup utility. 

[0084] Fall Back Utility 

[0085] Gate Poll Sequence 

[0086] If fallback enabled 

[0087] Ping fallback gateway addrl and addr2 

[0088] Else 

[0089] Exit. 

[0090] If both fallback gateways=«ALIVE 

[0091] Run /etc/ppp-off 

[0092] Ifconfig sps down 

[0093] Kill -9 nfd.pid's 

[0094] Run /etc/init.d/network script 

[0095] Call nfroute to re-establish tunnels on remote 
side. 

[0096] Notify remote peers to use our ethl IP 

[0097] In place of the previous pppO public IP. 

[0098] (cmd: nfroute -v -n [private net] -m [private 
net mask] -g [ethl IP address] -s [public IP of 
remote peer] 

[0099] Else 

[0100] Wait for next gateway poll sequence. 

[0101] Configuration 

[0102] Configuration information for ppp and polling is 
stored in the following files: /etc/ppp/DialBkup.cfg 
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[0103] Delay=n Where n=delay time in seconds 

[0104] Idaddrl«addrl Where addr=a standard IPV4 
address in dot notation 

[0105] Iaddr2=addr2 Where addr=a standard IPV4 
address in dot notation 

[0106] Retry=n Where n«the number of times to retry 
a polling sequence before Determining a connection 
is down. 

[0107] Frequency=n Where n*the number of con- 
secutive pings to send in 1 polling Sequence. 

[0108] /etc/ppp/ppp-on 

[0109] ACCOUNT-Username assigned by the ISP 

[0110] PASSWORD-Username's account password 

[0111] TELEPHONE=ISP's telephone number 



Dial Backup Component Files Used 
File and Location Description 

/etc/pppDialBkup.cfg Dial backup polling parameters. 

dialbkup The dial backup utility which is the executable 

created at compile time, 
/etc/ppp/getip An awk script used to extract the dynamic IP 

address assigned by an ISP. 
/etc/getgw An awk script used to extract the pppO gateway, 

/etc/getnm An awk script used to extract ethO's netmask 

/etc/ppp/ppp-on The pppd startup script called by dialbkup when 

establishing a ppp connection, 
/etc/ppp/ppp-off The pppd script called to kill the current ppp ISP 

connection. 

/etc/ppp/ppp-on-dialer The ppp script used to communicate with the 

external modem attached to COM1. 
/tmp/dbon Indicator file used by cron to start dialbkup. 

/tmp/keepalive.log The log file created by the dialbkup utility at start 

time. Information is also stored in the 

/var/log/messages file. 
/tmp/LOCAL_IP A text file use to store the current ppp IP address 

assigned by an ISP. This file is created by the 

getip awk script. 

Amp/GATEWAY A text file used to store the pppO gateway address 

assigned by an ISP. This file is created by the 
getgw awk script. 

Amp/NETW A text file used to store the private ethO network 

address. This information is used if IP 
masquerading is enabled and is created by gelnm. 

Amp/NETMASK A text file used to store the private ethO network 
mask. This information is used if IP 
masquerading is enabled. 

Amp/keepalive The file created by the dialbkup utility which 

stores responses received during a polling 
sequence. 

dialbkup.c The "C" source file for dialbkup. 



[0112] While there have been shown and described and 
pointed out fundamental novel features of the invention as 
applied to preferred embodiments thereof, it will be under- 
stood that various omissions and substitutions and changes 
in the form and details of the devices illustrated, and in their 
operation, may be made by those skilled in the art without 
departing from the spirit of the invention. For example, 
although not illustrated, it should be understood that net- 
work translation device 70 may also have a secondary 
backup interface. It is expressly intended that all combina- 
tions of those elements which perform substantially the 
same function in substantially the same way to achieve the 



same results are within the scope of the invention. It is the 
intention, therefore, to be limited only as indicated by the 
scope of the claims appended hereto 

What is claimed is: 

1. A network interface device comprising: 

a primary interface to interface with a public network over 
a primary connection; 

a back-up interface to interface with the public network 
when the primary connection fails; and 

a back-up utility for monitoring whether a primary con- 
nection between the primary interface and the public 
network has failed and for activating a secondary 
connection between the back-up interface and the pub- 
lic network when the primary connection fails. 

2. The network interface device of claim 1, wherein the 
primary and back-up interfaces link a node of a virtual 
private network to a public network. 

3. The network interface device of claim 2, wherein the 
node comprises one of a computer and a network of com- 
puters, and wherein the network interface device further 
comprises a private interface to the node. 

4. The network interface device of claim 1, wherein the 
primary interface comprises an Ethernet interface. 

5. The network interface device of claim 4, wherein the 
back-up interface comprises a dial-up interface to the public 
network. 

6. The network interface device of claim 5, wherein the 
public network is the Internet and the dial-up interface is 
connected to an Internet service provider upon a failure of 
the primary connection. 

7. A method for automatically activating a back-up con- 
nection to a public network when a primary connection to 
the public network fails, the method comprising; 

providing a network interface device comprising a pri- 
mary interface to interface with a public network over 
a primary connection, and a back-up interface to inter- 
face with the public network when the primary con- 
nection fails; 

monitoring the primary interface to determine whether the 
primary connection has failed; and 

automatically connecting to the public network through 
the back-up interface to provide a secondary connec- 
tion thereto when the primary connection fails. 

8. The method of claim 7, wherein the step of monitoring 
the primary interface comprises periodically polling a target 
IP address through the primary interface. 

9. The method of claim 8, wherein the polling comprises 
sending ICMP pings to the target IP address. 

10. The method of claim 7, wherein the back-up interface 
is connected to a modem, and wherein the step of automati- 
cally connecting to the public network through the back-up 
interface comprises automatically dialing an Internet service 
provider with the modem. 

11. The method of claim 7, further comprising: 

activating the secondary connection by rerouting links in 
the network interface device from the primary interface 
to the back-up interface to enable the secondary con- 
nection. 
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12. The method of claim 7, further comprising: 

determining whether the primary connection can be 
restored; 

restoring the primary connection when possible, the 
restoring of the primary connection comprising discon- 
necting the secondary connection. 

13. The method of claim 12, wherein the restoring step 
comprises automatically restoring the primary connection. 



14. The method of claim 12, wherein the primary and 
secondary connections connect nodes of a virtual private 
network that uses tunnels to send data securely over the 
public network, and wherein the method further comprises 
re-establishing tunnels for the virtual private network 
through the back-up interface when the primary connection 
fails. 

***** 
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